本系列已出版《Agile一本通！敏捷新手入門導引》，增加了更棒更豐富的內容，都進來了不看一下嗎?
了解一下這邊請>> https://www.books.com.tw/products/0010968755

新加入團隊的幼貓，好奇地提出問題。

「user story 跟 WBS長得好像喔，user story看起來不就是有連線的WBS嗎?」

幼貓google了一下

WBS

user story mapping

「欸那product backlog又是什麼?把待辦列成直的?越重要放越上面?」

幼貓再google了一下

product backlog

灰貓露出微笑，好像看到當年的自己，打開conflunce跟幼貓分享自己整理的筆記。

user story vs product backlog

product backlog的組成，必須基於user story。在user story mapping中，先定義使用者的目標、活動與細節的事項
(圖片來源:參考資料4)

當user story mapping 定義完需要做的task，再依照重要、必要程度，切分各次release的功能

(圖片來源:參考資料4)

再將需完成的功能依重要程度放入product backlog，再分成sprint backlog，列出每個sprint需完成的開發項目

user story vs WBS

WBS(Work Breakdown Structure)主要應用於瀑布式開發，其精神與scrum 應用的user story不同。

瀑布式開發希望盡可能、盡早把專案時程、所需資源規劃出來，規劃的範圍除了設計、開發、測試等事項，也包含大小會議、報告、文件。

而scrum精神，可運作的軟體比詳盡的文件重要、重視與客戶的協作，故user story中的task不會列入會議與文件、著重在功能的設計、開發與測試。

兩者的相似功能

列出每個任務的待辦事項，讓團隊裡的每個角色:

1. 開發者:了解每項任務的具體內容
2. 管理者:藉由任務內容，預估時程、安排資源
3. 測試者:設計符合任務目的測試方式

今天的參考資料/延伸閱讀:

1. 不管是敏捷式、瀑布式，規劃原理都是一樣的！
2. PM的牛肉在哪裡？再談WBS
3. 提到多種WBS的種類:Managing Software Project Scope: WBS vs. Product Backlog
4. 生動易懂的影片:Agile Product Backlog with User Story Mapping
5. Scrum Estimation－如何估算專案時程